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1.  OVERVIEW 

This  Quarterly  Technical  Report,  Number  2,  describes  aspects 
of  our  work  on  the  ARPA  Computer  Network  under  Contract  No. 
F08606-73-C-0027  during  the  second  quarter  of  1973.  (Work  per¬ 
formed  from  1969  through  1972  under  Contract  No.  DAHC-15-69-C-0179 
has  been  reported  in  another  series  of  Quarterly  Technical 
Reports  numbered  1-16.) 

During  the  quarter  we  delivered  two  TIPs,  one  to  the  Norwegian 
Seismic  Array  (NORSAR)  in  Kjeller,  Norway,  ana  one  to  the 
University  of  London  in  London,  England.  By  the  en^:  of  the 
quarter  the  NORSAR  TIP  was  functioning  correctly  and  the  Univer¬ 
sity  of  London  TIP  was  undergoing  final  installation  testing. 

The  NORSAR  TIP,  which  was  installed  in  mid-June,  is  connected 
to  the  network  at  the  Seismic  Data  Analysis  Center  (SDAC)  via  an 
ITT  satellite  circuit  which  is  intended  to  be  operated  at  9.6 
kilobits/second.  This  circuit  replaces  an  earlier  circuit  be¬ 
tween  SDAC  and  NORSAR  which  was  operated  at  2.4  M lobits/second 
and  used  for  an  entirely  separate  application.  Since,  in  the 
short  term  at  least,  the  previous  use  of  the  circuit  is  required 
to  continue  unchanged,  it  was  decided  to  multiplex  two  separate 
data  streams  (generated  by  the  AdrA  Netvork  and  by  the  other 
application)  into  the  new  circuit.  Accordingly,  Codex  9600 
modems,  with  a  multiplexor  option,  were  obtaiued  and  installed 
both  at  SDAC  and  within  the  NORSAR  TIP.  These  modems  can  be 
set  uo  operate  at  4.8,  7.2,  or  9.6  kilobits/second  by  switch 
selection;  thus,  from  the  IMPs ■  point  of  view,  the  circuit  speed 
is  2.4,  4.8,  or  7.2  kbs,  while  the  other  application  obtains  a 
constant  2.4  kbs  regardless  of  the  total  data  rate  being  carried 
by  the  circuit. 
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Because  of  the  shared  use  of  the  circuit  from  3DAC  to 
NORSAR,  the  low  speed  of  the  circuit  (as  compared  to  other 
Network  circuits),  the  use  of  a  new  type  of  modem,  the  5-hour 
time  difference  between  Norway  and  the  Network  Control  Center, 
and  the  involvement  of  a  new  carrier  (ITT),  we  experienced  a 
great  deal  of  difficulty  in  checkout  and  use  of  the  circuit. 
Although  the  NORSAR  TIP  has  been  connected  into  the  Network  for 
several  periods  of  a  few  hours  each,  and  for  many  periods  of 
5-20  minutes,  it  has  been  isolated  from  the  Network  for  most  of 
its  two  weeks  of  operation.  We  anticipate  that  several  more 
weeks  will  be  spent  before  the  problems  of  measuring  line 
performance ,  coordinating  trouble  reporting,  and  obtaining 
repair  activity  are  resolved. 

The  London  TIP  was  delivered  in  late  June  and  at  the  end 
of  the  quarter  was  undergoing  installation  testing.  It  will  be 
connected  to  the  NORSAR  TIP  via  Codex  modems  and  a  9.6  kilobit/ 
second  circuit  which  is  being  supplied  by  the  British  Post  Office. 
It  Is  our  current  understanding  that  this  circuit  will  not  be 
available  until  mid-August  at  the  earliest,  and  may  be  delayed 
into  September. 

Development  of  the  High  Speed  Modular  IMP  continued  through 
the  quarter.  Several  modules  of  code  have  been  debugged  In  a 
one-processor  system,  and  a  four-bus  hardware  configuration  has 
been  successfully  tested.  Section  2  contains  a  review  of  our 
progress . 

During  the  second  quarter  we  have  been  engaged  In  the  design 
of  a  specialized  "minl-Host ” ,  called  the  Private  Line  Interface 
(PLI),  at  ARPA’s  request.  We  anticipate  that  early  in  the  third 
quarter  ARPA  will  provide  funding  for  construction  of  two  or 
cnese  devices.  The  motivation  for  the  device  and  a  review  cf 
our  planning  are  contained  in  Section  3. 
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Our  Quarterly  Technical  Report  Number  1  described  two 
planned  IMP  program  changes  related  to  checksumming;  extension 
of  packet  software  checksums  to  detect  intra-IMP  failures  and 
checksumming  certain  critical  portions  of  the  IMP  code  on  a 
periodic  basis.  These  changes  were  implemented  during  the 
second  quarter  and  described  to  the  Network  Working  Group  (NWG) 
via  the  RPC  mechanism. 

Another  task  which  was  continued  from  the  first  quarter  was 
the  development  of  the  TELNET  and  File  Transfer  Protocols. 

During  the  second  quarter  we  produced  a  final  version  of  the 
documentation  of  the  new  TELNET  Protocol  and  three  drafts,  for 
committee  review,  of  the  new  File  Transfer  Protocol  documentation. 
We  anticipate  that  the  last  of  these  drafts  will  be  published 
as  a  final  document  early  in  the  third  quarter. 

The  IMP/TIP  memory  retrofit  program,  described  i ~  Section 
1.1  of  cur  Quarterly  Technical  Report  No.  1,  was  completed  late 
In  the  second  quarter.  During  the  third  quarter  we  will  move  the 
code  in  all  TIPs  to  the  memory  area  above  the  16K  boundary  and 
thus  make  a  contiguous  16K  block  of  memory  available  to  the  IMP 
program  in  all  machines. 

Section  1.3  of  our  last  report  described  the  growth  of  Host 
traffic  during  the  18-month  period  ending  with  March,  1973. 

During  the  past  quarter  the  traffic  appeared^  relatively  stable, 
with  about  2  A  million  packets  entering  the  Network  each  day  on 
the  average.  It  is  too  early  to  tell  if  this  leveling  off  of 
traffic  growth  is  due  to  seasonal  factors  or  if  it  is  because 
the  most  popular  service  Hosts  have  reached  a  saturation  point; 
there  is  some  evidence  to  support  each  of  these  tneories.  In 
any  case,  the  IMPs  and  circuits  still  appear  to  be  well  below 
\  the  saturation  level. 
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During  the  second  quarter  we  concluded  the  first  phase  of 
our  study  of  net work  routing  algorithms  and  presented  informal 
reports  of  our  findings  and  recommendations  to  ARPA  and  other 
interested  parties.  A  meeting  was  subsequently  held  at  the 
ARPA  office,  and  agreement  to  install  the  first  set  of  major 
changes  was  readied.  These  changes  will  be  installed  as  a 
series  of  smaller,  and  at  each  step  compatible,  changes  so  as 
to  avoid  major  disruptions  of  network  operation.  By  the  end 
of  the  quarter  we  had  begun  the  coding  and  checkout  of  the 
first  st°ps  of  the  change.  We  will  report  on  these  new  al¬ 
gorithms  in  a  later  report,  after  they  have  been  c  npletely 
coded  and  released. 

There  has  been  a  fairly  large  effort  during  the  quarter  in 
the  field  of  satellite  communication.  Early  in  the  quarter  we 
visited  COMSAT  and  discussed  our  experience  with  the  California- 
Hawaii  satellite  circuit.  In  particular,  this  circuit  experiences 
a  relatively  large  number  of  very  short  (less  than  30  second) 
outages.  The  COMSAT  staff  has  expressed  a  great  deal  of  interest 
in  our  measurement  techniques  and  experience  with  the  circuit, 
and  we  are  now  supplying  them  with  a  weekly  listing  of  all  cir¬ 
cuit  difficulties. 

We  are  continuing  our  development  of  the  Satellite  IMP 
hardware  necessary  for  "broadcast*1  use  of  a  satellite  channel. 
During  the  quarter  we  constructed  and  debugged  the  mod * f ications 
to  the  SIMPs’  modem  Interfaces  necessary  for  "slotting”  use  of 
such  a  channel.  These  modified  interfaces  are  now  installed  or 
the  two  SIMPs  at  BBN  which  are  awaiting  delivery.  We  also 
participited  in  the  session  on  Satellite  Packet  Communications 
at  the  1973  National  Computer  Conference  and  Exposition. 
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Daring  the  quarter  we  began  storing  the  Host  and  line 
traffic  statistics,  which  are  collected  by  the  Network  Control 
Center  machine,  on  the  BBN  TENEX  system.  In  general,  the  TENEX 
on-line  storage  contains  complete  hourly  Host  and  line  throughput 
summaries  for  the  few  preceding  days,  and  a  set  of  24-hour 
summaries  for  the  previous  days  of  the  current  month.  Due  to 
disk  space  considerations,  each  day’s  worth  of  hourly  summaries 
is  archived  after  roughly  three  days.  Documentation  of  the 
naming  conventions  for,  and  internal  structure  of,  these  files 
has  been  distributed  to  a  few  interested  parties;  the  documenta¬ 
tion  has  not  yet  been  made  generally  available  because  we  are 
currently  investigating  suggested  changes  to  the  structure  of 
the  data  being  stored,  but  will  probably  be  distributed  during 
the  third  quarter. 

Coding  of  the  RJE  mini-Host  was  begun  during  the  second 
quarter.  As  described  in  Section  1.1  of  our  Quarterly  Technical 
Report  No.  16*,  this  device  will  be  built  from  the  sam^ 
components  as  are  used  in  the  rICMIM?  and  is  designed  to  inter¬ 
face  to  a  small  number  of  IBM  2780  remote  batch  terminals  and 
to  jn  IMPs  ’  standard  Host  interface.  Thus,  the  RJE  mini-Host 
will  c^ovide  a  low-cost  mechanism  for  connectirg  remote  batch 
oerminalc  directly  to  the  network.  The  mini-Host  will  be 
programmed  to  translate  between  standard  2780  line  protocol  and 
Network  "Remote  Job  Entry"  Protocol.  The  majority  of  the  hard¬ 
ware  -.md  software  design  ha°  been  completed,  and  parts  have  beer; 
ordered  for  the  construction. of  a  prototype.  Debugging  of  the 
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main-line  code  can  probably  commence  during  the  third  quarter, 
and  to  this  end  we  have  signed  an  order  for  short-term  lease  of 
an  IBM  2780  terminal.  Additional  details  of  the  RJF.  mini-Host 
design  will  be  provided  in  a  subsequent  report. 

V/e  have  continued  our  interaction  with  the  International 
Network  Working  Group  (INWG)  during  the  past  quarter.  In 
particular,  we  attended  a  working  meeting  of  the  INWG  during 
June  and  contributed  to  the  design  of  a  "gateway”  protocol  which 
is  currently  under  consideration. 

Finally,  the  second  Quarter  saw  the  publication  of  major 
updates  to  three  BBN  manuals,  namely:  BBN  Report  No.  1822, 
Specifications  for  the  Interconnection  of  a  Host  and  an  IMP ; 

BBN  Report  Mo.  1877,  IMF  Operating  Manual ;  BBN  Report  No.  2277, 
Specifications  for  the  Interconnection  of  Terminals  and  the 
Terminal  IMP . 
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2.  HIGH  SPEED  MODULAR  IMP 

This  quarter  has  been  a  difficult  phase  for  the  HSMIMP  hard¬ 
ware  development,  and  we  have  not  made  as  much  progress  as  we  had 
hoped.  The  bus  coupler  manifested  a  number  of  problems  whan  we 
enlarged  the  growing  prototype  to  a  four-bus  system;  these  prob¬ 
lems,  because  they  were  sophisticated,  occurred  in  a  complex 
system,  and  interacted  with  problems  in  the  Lockheed  processor, 
have  taken  a  great  deal  of  time  to  locate  and  fix.  Further,  in 
designing  the  printed  circuit  layouts,  it  has  turned  out  that 
the  bus  coupler  cards  do  not  quite  fit  onto  two  layer  boards;  the 
necessary  change  to  boards  with  more  than  two  layers  has  intro¬ 
duced  further  delays.  Finally,  we  have  had  undiminished  problems 
in  getting  Lockheed  updates  to  cur  processors.  The  result  of  all 
this  is  that  the  full  scale  prototype  is  behind  schedule,  and  we 
have  set  our  sights  on  an  intermediate  goal  of  a  smaller  proto¬ 
type  consisting  of  three  processor  busses,  two  memory  busses  and 
two  I/O  busses.  In  fact,  after  reviewing  the  issues  of  relia¬ 
bility  and  graceful  degradation  we  have  decided  to  put  two  I/O 
busses  on  all  the  large  machines  (the  prototype  and  both  of  the 
large  production  machines),  thus  avoiding  total  system  dependence 
on  any  single  unit. 

We  are  amidst  conversion  of  the  prototype  cards  into  produc¬ 
tion  format.  For  most  of  the  cards  this  means  printed  circuit 
layout,  etc.  The  DMA  card  has  been  made  in  "multi-wire"  form 
and  that  technique  has  proved  highly  successful.  (Multi -wire  is 
a  single-source  technique  intermediate  between  wire- wrap  and 
i  ri.nted  cir  cuit.  It  is  mechanically  less  cumbersome  than  wire- 
wrap,  but  more  easily  admits  several  circuit  layers  ban  printed 
circuits.)  However,  it  is  more  costly  than  a  printed  circuit; 
in  addition  the  production  queue  length  has  grown  greatly  in 
the  past  few  months. 
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A  description  of  the  test  program  facilities  and  testing 
accomplished  thus  far  give  the  best  indication  of  where  we  stand. 
The  most  complex  system  tested  to  date  consists  of  two  processor 
busses,  a  memory  bus,  and  an  I/O  bus.  Pour  bus  couplers  cornect 
each  processor  bus  to  the  memory  bus,  and  each  processor  bus  to 
the  I/O  bus.  The  test  program  has  teen  run  with  one  processor 
per  processor  bus.  (Mult i-processor-per-bus  operation  5s  not 
yet  possible  because  of  delays  in  getting  some  necessary  processor 
corrections  made  by  Lockheed. )  The  program  uses  two  processors 
(on  separate  processor  busses)  e i  h  running  code  out  of  its  own 
local  memory.  Ir  addition,  the  consoles  on  the  processor  cusses 
can  be  used  to  do  repeated  common  memory  accesses,  thereby  in- 
q r^us ing  contention  for  bus  usage. 

The  test  program  is  loaded  into  local  memory  on  one  of  the 
processor  busses  and  immediately  copies  itself  into  the  local 
memory  of  the  other  processor  bus  (using  backwards  bus  coupling 
vie  the  I/O  bus).  Then  (a Ire  by  backward  coupling 5  tne  processor 
on  the  remote  bus  is  started.  The  running  program  then  exercises 
backward  b'u  coupling  concurrent  with  forward  accessing  to  the 
memory  l  .ock  (which  interlocks  the  backward  accesses)  and 

counts  ^  .  ir'ns  for  access  to  the  lock.  Once  a  processor  gains, 

access  t  *ock  It  uses  the  .ackward  path  to  test  a  location 

in  the  other  processor's  local  memory.  This  test  program  has  run 
without  errors  overnight  concurrent  with  repeated  reading  of 
common  memory  from  both  u  ncessor  bus  consoles. 

The  coding  and  debugging  of  the  operational  IMP  program  is 
well  underway.  During  the  first  quarter  our  major  emphasis  was 
or.  coding  the  store-and-for^ard  path  of  th^  program,  and  that 
path  has  since  been  made  to  work  in  the  n  >st  simple  environment. 
Emphasis  then  shifted  to  bringing  up  the  Host  and  Fake  Host  code 
to  a  similar  state,  since  it  is  easier  to  debug  everything  once 
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the  main  pieces  work  in  some  fashion.  HOST  is  coded  and  de¬ 
bugging  has  started.  FAKE  HOST  is  in  the  nrocess  of  being  coded 
although  the  Discard  and  the  Message  Generator  portion  of  Statis 
tics  are  being  debugged  with  HOST. 

S^j  far  all  debugging  has  been  on  a  simple  one  processor  one 
bus  system,  both  because  it  made  sense  to  get  the  simpler  system 
working  first  and  because  the  growing  multiprocessor  has  been 
fully  given  over  to  hardware/test  program  debugging.  During  the 
third  quarter  we  expect  to  debug  the  multiprocessor  aspects  of 
the  program.  The  multiprocessor  mechanisms  have  been  coded  but, 
of  course,  do  not  come  into  play  in  a  single  processor  system. 

We  continue  to  exchange  information  on  the  HSMIMP  design 
with  other  interested  groups  and  individuals.  In  particular, 
during  the  past  quarter  one  member  of  the  hardware  design  group 
attended  the  international  Workshop  on  Computer  Architecture. 
Even  more  notably,  we  presented  our  design  in  a  paper  entitled 
4  flew  Minicorriputer/MultipvoQes sor  for  the  ARPA  Networ<  at  the 
1973  National  Computer  Conference  and  Exposition. 
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3.  ThE  PRIVATE  LINE  INTERFACE 

During  this  quarter,  BBN  began  studying  techniques  for 
transmitting  private  data  through  the  ARPA  Network.  We  new  be¬ 
lieve  chat  the  proper  approach  is  to  develop  a  small  machine,  a 
’’ Private  Line  Interface1’  or  PLI,  which  would  act  as  a  Host  to 
the  Network  and  would  be  logically  located  between  the  data 
source  or  sink  and  the  nearest  IMP.  Thus,  a  pair  of  PLI's  will 
provide  a  subscriber  with  the  ability  to  use  the  AhPA  Network 
as  a  private*  leased  communications  line.  A  FLI  w ill  consist  of 
a  two  processor,  single  Infibus,  Lockheed  SUE  system  fitted  with 
appropriate  interfaces  for  the  Host  system  and  the  Network.  In 
designing  the  PLI  we  have  isolated  two  independent  areas  of  re¬ 
search;  effecting  transparent  transmission  of  a  continuous  bit 
stream  over  the  Network,  and  possibly  encrypting  the  bit  stream 
to  secure  the  transmission. 

Currently,  it  is  sometimes  difficult  for  certain  existing 
systems,  or  some  planned  ’’simple-minded”  systems,  to  take  advan¬ 
tage  of  the  ARPA  Network  technology.  For  such  installations , 
even  the  effort  of  i \  -eg rating  the  relatively  simple  IMF/Host 
(Level  0)  Protocol  into  their  systems  presents  a  considerable 
burden.  One  puroose  of  the  PLI  is  to  eliminate  this  problem  and 
open  tiie  Network  to  these  pot:ntial  users,  who  could  then  use 
it  in  lieu  of  a  point-to-point  communi cation  circuit. 

We  have  approached  this  problem  by  designing  the  PLI  to 
appear  tc  a  source  system  as  some  standard  modem  which  the  sys¬ 
tem’s  software  (and  hardware)  is  already  able  to  service.  In 
particular,  we  are  currently  designing  an  interface  which  will 
appear  to  be  a  standard,  full  duplex  Dell  System  type  303  modem. 
During  the  third  qu  rter  we  will  imestigate  also  providing  a 
standard  voice-grade  as;,  knronous  2^00  baud  interface  for  the 
PLI . 
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In  order  to  make  more  efficient  use  of  the  Network,  and 
hence  decrease  the  resultant  costs,  the  303  interface  is  being 
designed  to  take  advantage  of  the  fact  that  many  users  of  303s 
utilize  SYN  characters  to  fill  the  line  when  they  have  no  data 
for  it  (i.e.,  to  indicate  an  idling  state).  If  code  can  be 
written  for  the  PLI  to  determine  the  actual  message  boundaries 
in  the  source Ts  bit  stream*  the  PLI  will  be  able  to  automatically 
elide  all  SYNs  between  messages,  eliminating  the  expense  of  send¬ 
ing  the  inter-message  padding  through  the  Network.  Similarly  on 
output,  if  a  Network  delay  should  cause  an  interruption  in  the 
lata  stream,  the  PLI  will  ’’cover”  the  interruption  by  sending 
SYNs  until  the  next  message  arrives. 

Where  ”SYN  suppression”  cannot  be  done,  the  PLI  will  ’’stop 
the  clock”  when  it  either  can  accept  no  more  input  (because  its 
internal  buffers  are  full)  or  has  no  more  output  to  send  (because 
l.ie  next  message  has  not  yet  arrived).  Standard  303  modems  pro¬ 
vide  the  data  clock  for  both  Input  and  output.  Thus,  suspending 
the  clock  in  one  direction  or  the  oth-  r  presents  few  problems  to 
the  PLI,  and  our  preliminary  invest Ir  it  ions  indicate  that  usual 
system- to- 30 3  interfaces  are  immune  to  an  occasional  suspension 
of  the  clock**. 

ri  h°  software  in  the  PLI  will  drive  the  attached  system’s 
interface,  breaking  up  input  into  messages  fo*'  network  trans¬ 
mission  and  concatenating  received  messages  to  reconstruct  the 
bit  stream  for  output.  The  PLI  will  also  handle  all  of  the 

*~The  feasibility  of  this  Is  strongly  dependent  upon  the  line 
protocol  the  source  is  using.  For  example,  it  is  simple  if 
the  source  sends  only  messages  of  some  fixed  length. 

** Indeed,  the  protection  circuits  in  such  interfaces  appear  to 
concent rate  on  preventing  the  303  from  running  too  fast, 
r  1 1  h o r  t  h a n  too  : 1 o w . 
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IMP/Host  protocol  and,  if  necessary,  the  VDH  protocol.  Tims,  a 
facility  could  use  a  pair  of  PLls  to  replace  an  already  existent 
private  line  with  no  other  impact  than  a  probable  improvement  in 
the  line’s  apparent  reliability  and  a  decrease  in  communications 
costs . 


The  security  issue  is,  at  once,  both  more  straightforward 
and  more  complicated  than  the  transparency  issue.  At  the  simple 
level,  we  are  considering  the  design  of  interfaces  to  drive  a 
security  unit  as  a  peripheral  on  the  PI  I.  All  source  data  could 
be  encrypted  in  the  PLI  before  transmission  through  the  network 
and  decrypted  in  tne  PLI  before  being  delivered  to  the  destina¬ 
tion;  the  leader  could  be  sene  through  the  Network  in  the  clear. 
Thus  in  a  fairly  simple  fashion,  question®  «f...rhe  security  of 
tne  data  could  be  effectively  isolated  from  the  Network. 


We  have  been  designing  the  PLI  in  constant  awareness  of  the 
fact  that  one  of  the  most  important  prone riles  of  the  PLI  should 
ba  its  flexibility.  With  a  relatively  small  hardware  repertoire, 
a  PLI  will  be  able  to  appear  to  a  system  as  almost  any  standard 
modem.  The  software,  however,  will  have  to  provide  for  a  great 
deal  more  variety.  Even  at  this  early  state  of  development  we 
c-  already  see  a  large  number  of  potential  options:  the  PLT. 
should  be  switehable  to  a  VDIi  Network  connection;  the  PLI  could 
maintain  two  or  more  independent  source  bit  streams  over  the 
jingle  interface,  and  the  bit  streams  could  be  directed  to  dis¬ 
tinct  destinations;  the  PLI  can  have  various  buffering  strategies 
to  match  the  attached  system  ’  needs  (e.g.,  the  data  could  incur 
only  t  fixed  delay,  but  portions  might  occasionally  be  lost,  or 
the  data  transmission  could  be  ” guaranteed” ,  but  the  delays  it 
incurred  would  vary.  Further,  i*  should  be  easy  to  enable  and 
disable  the  various  options,  ‘ o  allow  the  users  of  an  attached 
system,  to  experir^nt  to  determine  the  correct  set  to  match  local 
needs  . 
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During  the  third  and  fourth  quarters  of  1973  we  will  be  con¬ 
tinuing  to  work  out  the  design  of  the  PLI  and,  if  funding  is 
arranged,  we  will  be  constructing  two  pairs  of  PLIs. 


